First you build the tools

Before I begin writing a game for my Nintendo DS, I first need to make sure I have the correct tools for the job. I’ve got devkitARM installed and working, the No$GBA emulator works well enough for my debugging needs so what more do I need?

Well I come from a Windows programming background, and one of the nice things Microsoft give you is a load of templates to base your software on. Writing code requires the programmer to do the same thing every time – there’s one way to open a screen, one way to get user input, one way to set up a main menu loop. Having to type all that out every time is a huge waste of energy.

I’ve just finished creating my own “game engine” that should save me lots of time and effort in the future. I have a system with sprites, title screens, a menu screen and space for the game. By copying a directory full of code, swapping some images and deleting a bit of placeholder code I have a ready-made framework to put my games into. All the time consuming effort of converting image data, loading it into the program and getting it on the screen is now done for me and wrapped into convenient functions. It’s the kind of background stuff that makes for very boring screenshots so instead here is a bit of technical information about it.

My “engine” is written in C++ (ever tried switching between C++ and C#? It’s fun) and contains several key objects. There is a Sprite object and a SpriteManager class which is responsible for keeping track of the sprites, testing for collisions and so on. There is also a Screen class which represents a single “screen” in the engine. A Screen can be anything from a splash/title screen, menu or the game itself. Each Screen object is a mini program with a main Run method. A corresponding ScreenManager class keeps these in a list and cycles through them, calling the Run method on each in turn.

The clever part is that Screens run in endless loops, waiting for some quit status to happen. So the program might go into the main menu screen and wait until the user hits the ‘Start’ button. Once this happens, the screen leaves the Run method and passes a value that corresponds to the next screen to display back into the ScreenManager.

So now I can chain screens together – It can go Splash Screen -> Title Screen -> Main Menu -> Game -> Game Over -> Main Menu. Each screen simply returns the Id of the next screen to go to. The code making this work is this simple:

next_screen = 0;
for (int i = 0; i < MAX_SCREENS; i++)
if (screen_list[next_screen] != NULL)
next_screen = screen_list[next_screen].Run();


And each Screen object’s Run method looks like this


next_screen_id = MAIN_MENU_SCREEN;
while (1) {
/* Do screen logic */
if (quit_condition)
break;
}
return next_screen_id;

Thanks to inheritance I can subclass the Screen class and create others based on it. The Game object represents the game itself. When I start a new game all I have to do is create a new Game object and fill in its Run method with the game logic.

All I’ve done is create a finite state machine, a very powerful way of controlling the flow of software. The other way to do this sort of system is with a giant if/then or switch/case statements, but it becomes complex and requires huge lists saying where to go next.

So, now I have this engine complete, what am I going to do? I’m going to make the gaming equivalent of “Hello World” – Pong! If in doubt, make Pong on it. And naturally, while doing this I will create various revisions and additions to the main engine code which will get rolled back into the main repository, ready for the next game.